Skip to content

Inverse Variance Track Time Averages.#1089

Merged
rodwyer100 merged 4 commits intomasterfrom
timefix
Mar 31, 2025
Merged

Inverse Variance Track Time Averages.#1089
rodwyer100 merged 4 commits intomasterfrom
timefix

Conversation

@rodwyer100
Copy link
Contributor

It is mathematically proven that the way to take a weighted average of independently, possibly nonidentically distributed, normal distributions is through inverse variance sampling. Namely you weight a time sample by the inverse of the square of its error. This push request aims to implement this change. It does so fairly successfully; I include a number of html files with various information about how the changes work. There are two caveats about this weighting scheme that are important to note. They first arises from the broad shoulder issue we have in the first two layers; the second from just hps-java architecture. That is, due to an irreducible degeneracy in hits (that was only partially solved by previous chi square probability manipulation) there is a significant degree of non gaussianity to the first two layer hit time distributions (particularly in layers nearmost to the detector).

  1. This seems to occasionally make the inverse variance timing average worse. To counteract this, the first two layers are removed from the averaging step. Don't worry; this doesn't mean they aren't involved in momentum and other things they are critical for; their removal just noticeably and significantly improves the mean. This makes this change almost uniformly an improvement.
  2. The HPS track time is calculated from Measurement site object in java. This is an object that, while it retains amplitude error information, it forgets everything to do with the time error. You can be sure about this because the KalmanPlotting classes have to re-obtain the Hit objects whenever they want to plot information about the time errors of hits. To circumvent this issue, I rerun fitting for hits on track to obtain their hit time error at the time that we cant to calculate track time. Luckily this change is ~10 lines; we don't need to do all the time translation junk that has to be done at the hit time step because the time error is invariant under time translation. Thats with the exception of the pileUp decision, where we retain the time closer to the track time. In this ase, I make the reasonable assumption that the hit time error of the chosen hit will be less than the other and use that time error (this is almost always true). It is with this choice I see the almost uniform improvement in the following plots:

Track Time:https://s3df.slac.stanford.edu/people/rodwyer1/timeFix/orChange/tracktime.html
Z Momentum of Track:https://s3df.slac.stanford.edu/people/rodwyer1/timeFix/orChange/pzonTrack.html (seemingly completely unchanged).

The change is small, but theoretically motivated. When yall look at the plots, and are convinced it is fine, I will also make changes to the jlab plot stuff (that will probably need to be done again)

@rodwyer100
Copy link
Contributor Author

Btw for those html plots, the changes were done on the distributions on the right (unchanged left). Only the first is slight worse; all other runs are slightly better.

@mgignac mgignac self-requested a review March 31, 2025 18:07
@mgignac mgignac requested a review from baltzell March 31, 2025 18:08
}
}
Variance=1.0/Variance;
Measurement m = new Measurement(umeas, xStrip, du, time, localHit.getdEdx()*1000000.,Variance);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really, this should be done in clustering but SiTrackerHit doesn't have a place for the error on the time. We do extend SiTrackerHit in hps-java at org.hps.recon.tracking.SiTrackerHitStrip1D and we could put the error in there but it wouldn't be saved to the LCIO. For now this is ok...I think we have some other changes to LCIO/lcsim we need to make so we should put this on the list.

@rodwyer100 rodwyer100 merged commit d684ab0 into master Mar 31, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants